\section{\blackBox{} Framework}
\label{sec:design}

\blackBox{} is a framework that is intened to provide critical insights that guide the design 
of energy-efficient HeCMPs that are targeted for a particular application domain while 
maintaining their general purpose characteristics. \blackBox{} combines a data-driven 
approach with linear regression models and optimization techniques to automatically 
generate HeCMP specifications. Given a set of applications and workloads as input, 
\blackBox{} is able to accurately determine a covering set of core designs that 
collectively constitute a general purpose energy-efficient HeCMP to execute those applications. 

\subsection{Outline of \blackBox{}}
\blackBox{} is used to generate a HeCMP that comprises of non-monotonic cores. A 
library of non-monotonic cores, which constitute the design space, is constructed 
by varying the configurations of various micro-architecture structures like caches, 
queues, and the issue/retire width. A small training set of applications is chosen 
from the targetted application space and for each training application or application 
phase, a vector of architecturally independent features is gathered from
MICA~\cite{Hoste07-IEEEMICRO-MICA} along with the associated energy-performance-area 
three-tuple for a given core. To architect a efficient HeCMP, the 
architecturally independent feature vectors of a target workload are fed into 
a trained \blackBox{}, along with constraints such as the maximum allowed degree 
of heterogeneity, denoted by \textit{K}. \blackBox{} then partitions the input 
applications up to \textit{K} groups and, for each group, estimates the energy and performance
of the group across all points in the design space. Finally,
\blackBox{} picks the optimal performance/watt configuration across
each group, selects that processor for inclusion in the CMP, and
provides a distance-based mapping function between the
architecture-independent features of any current or future application
and the predicted-preferred core type.

Currently, \blackBox{} is used to optimize for performance/Watt, but
the framework is general, and it can be tailored to take different
optimization objective functions. For instance, a designer may
consider using \blackBox{} to optimizing for performance given a
constrained power budget.

\subsection{Implementation of \blackBox{}}

\textbf{Design space definition:}  One of the first steps in designing
\blackBox{} is to determine the micro-architecture features, or knobs, that
the architect will have available in the processor creation search
space. Since HeCMPs trade among efficiency, performance
and area, care should be taken to select a set of knobs that have the 
most impact on these parameters. Examples of \blackBox{} configuration 
knobs include processor issue width and the type (inorder or out-of-order) 
and depth of the pipeline. \blackBox{} also sweeps cache size/structure 
and the provisioning of functional units. Components such as branch 
prediction and prefetchers are currently held fixed, but may later 
become additional parameters.

While the design space of all CMP configurations is already vast,
evaluating all potential programs across this space to find optimal
application to core mappings is not merely intractible, but
impossible: Viable processors must be able to effectively run
applications that do not yet exist and execute existing programs on
new inputs. To facilitate future mappings, \blackBox{} distills each
application phase in its training set into a concise description of
its micro-architecture-independent features~\cite{Hoste07-IEEEMICRO-MICA}.

\textbf{Power and performance modeling:}  Once the configuration knobs
are selected, \blackBox{} requires accurate power, area and
performance models for each target CMP architecture. \blackBox{} uses
these models to compare among the various knobs options and thus is
sensitive to accuracy in ordering. We use the McPAT~\cite{mcpat} power
and area modeling framework to calculate the $\Delta$-power/area
marginal change for each knob setting when adjusting a single knob and
holding all other parameters constant.  This provides an ordering
among optimizations without the need to run the framework for every
single possible configuration.

To drive McPAT in generating the marginal costs, we use
Gem5~\cite{gem5} simulations over a training set of application
phases, varying one of the knobs at a time while keeping the rest of
the processor constant.  Once each application has been processed for
both the simulation-based processor data and the architecture
independent variables, we combine the two into a single training set
and send it through a linear regression model~\cite{bLee} that
includes both the various processor knobs and the various
architecture-independent data points.  The linear regression model is
used to estimate the performance across the knob space while holding
the application data points fixed for any particular core fitting
exercise.

\textbf{Selecting optimized processor designs:}  Once the above steps
are completed, \blackBox{} is ready to generate optimized processor
designs.  \blackBox{} takes a target workload and a maximum number of
core types as an input. For workloads with more applications than core
types, \blackBox{} uses K-means clustering to reduce the set of
microarchitecture-independent characteristics of all workload
applications into no more than K ``meta-apps'' (where K is the max
number of core types). We then use these ``meta apps'' as the input
for \blackBox{} rather than relying on the application that is the
closest to the cluster median.

\blackBox{} performs a sweep of the knob search space, calculating the
projected performance, area, and power for each possibility, using its
internal regression model. The area and power metrics are determined
by increasing the projected value based on the introduction of more
components, while the performance is determined using the regression
equations given in the input. We perform this exhaustive search
because estimating for these knobs is still much quicker than
performing individual simulations, while also avoiding any pitfalls of
pruning the search space unnecessarily.

To obtain final performance measurements more accurate than those
provided by the model, the CMPs \blackBox{} selects as the best design
candidates are run through the Gem5 simulator. These numbers are
coupled with McPAT data generated from the same processors to allow us
to select the best core within the limited search space for the given
goal. \blackBox{} then reports the processors for each
application/cluster to the user.

One final step consists of adding the results of the Gem5 runs to the training
set, which allows the user to continuously tune the regression to
their workloads without having to retrain from scratch every
time. While in the end we do perform Gem5 simulations, they remain in
the order of tens of simulations versus the order of tens of thousands
for even basic heterogeneous core search spaces. 


\subsection{Instantiating the \blackBox{} framework}

We instantiate \blackBox{} to cover a broad spectrum of
applications. The idea is to perform both breadth testing, by looking
at a processor that was developed across all possible suites, as well
as doing some analysis on processors specifically designed with one
workload in mind. As a result, we drew from the desktop, embedded, and
HPC communities, selecting applications from the following benchmark
suites: SPEC2006 (Desktop), Parsec 2.1 (HPC), and Coremark (Embedded).

Our initial implementation of \blackBox{} uses the design space
described in Table~\ref{table:knobs}. Since current heterogeneous
designs focus on issue width and execution model, we use those design
options as a reasonable starting point. Our decision points for which
issue width and execution model combinations to analyze were based on
previous studies that look at the energy-performance tradeoffs of
these types of processors~\cite{horowitz}. We also focus on high power
components that can be scaled in various ways and have meaningful
impacts on power and performance. 

\begin{table}[tl]
   \centering
   \begin{tabular}{|p{1.5in}|p{1.5in}|}
	\hline
	\textbf{Component} & \textbf{Settings}\\
	\hline
	L1 Cache & 16KB/2-way I-D, 32KB/2-way I-D, 64KB/4-way I-D\\
	\hline
	L2 Cache & 64KB, 256KB, 1MB\\
	\hline
        Int ALUS & 1, 3, 6\\
	\hline
	Mul/Div ALUS & 1, 2\\
	\hline
	FP Units & 0, 1, 2\\
	\hline
	Instruction Window Size (for OoO models) & 64, 128, 200\\
	\hline
	Issue Width \& Execution Model & 1-IO, 2-IO, 4-IO, 4-OoO, 8,OoO\\
	\hline
   \end{tabular}
   \caption{Knob Selection for Raven Experiments}
   \label{table:knobs}
\end{table}


The current selection of knobs also
influences our selection of architecture-independent variables to use
in describing applications:
\begin{itemize}
\item Integer, Floating Point, Branch, and Memory Access Instruction Rates;
\item How much memory passes through the processor in a given simpoint (its footprint);
\item Average data reuse and the percentage of data reuses in a short distance;
\item Register operand average;
\item Average register producer-consumer rate.
\end{itemize}


For our baseline design, we selected a homogeneous processor using the
midpoint settings for all knobs.  This produces a 4-wide OoO processor
we call \emph{Midway} with an aggressive performance/watt target that
does not penalize against compute-bound workloads (much like current
consumer processors). We use Midway to normalize our
performance-energy-area tuple so that we can focus on improvements
starting from a hypothetical homogeneous core model presumed to be
designed with performance/watt as a goal, rather than trying to
normalize around an extreme processor that may have equally extreme
goals in power, energy, area, or performance at the expense of the
other dimensions.
